Computer systems may include computer components that are operably connected together by, for example, a bus and/or a port(s) into point-to-point (P2P) links. Components operably connected by a bus typically “listen” to substantially every request placed on the bus and “hear” substantially every response on the bus. To facilitate listening, hearing, and the like, various bus communication techniques, timings, protocols, transaction formats, packet formats, and so on, have evolved. Thus, a transaction like a data read in a bus model system may include producing and monitoring various phases (e.g., arbitration, requests, snooping, data) and sending/receiving various packets of information during these phases. The packets may include, for example, header sections and data sections.
Systems whose computer components are operably connected by P2P links may operate substantially differently than those whose components are connected by a bus. There may be packets associated with P2P link networks that do not directly correspond to packets associated with bus-type systems. Similarly, information that may be transmitted as data in one system (e.g., P2P) may be treated as header information in the other system (e.g., bus). In a P2P system, a transaction (e.g., data read) may be performed by sending and receiving packets and/or flits between various source and destination components. Typically, a P2P packet includes a header flit(s) and a data flit(s). The data flit(s) typically store actual data values from a computer memory, but in some cases information other than data values may be encoded in a data flit(s). For example, header information that may overflow a P2P packet header may be stored in a data flit(s).
In environments like processor verification and hybrid multi-processing, some components may be connected by a bus like a front-side bus (FSB) and other components may be connected by P2P links. FSB connected systems perform certain actions in certain ways. For example, messages intended for one component may be broadcast on the FSB, received by all components operably connected to the FSB, and acted on by target components. P2P link connected components perform certain actions in certain other ways. For example, packets may be transmitted between specific components with a crossbar “traffic cop” responsible for directing packets/flits. Since both FSB connections and P2P connections have strengths and weaknesses it is not surprising that some computer systems are FSB connected while others are P2P configured. In some examples, a multiprocessor system or other computing system may even include computer components that are connected using both methods.
Tools have developed for designing, analyzing, testing, and so on, systems that use a bus model to connect components. Other tools have developed for designing, analyzing, testing, and so on, systems that use a P2P model to connect components. Since the two systems are fundamentally different, a tool known as a virtual bus interface (VBI) was developed to facilitate producing bus-type transactions from P2P transactions. This may in turn facilitate communication between systems employing a bus model and systems employing a P2P model and/or correlating results from different tools. But, as described above, the conceptual and logical structure of P2P transactions differs fundamentally from that of bus transactions. For example, what is a header field in one model may be a data field in another model, and vice versa. In some cases, data that may have been too extensive to reside in a header in a transaction from one model may comfortably fit in a header in a transaction from another model. In other cases, information that is stored in a data flit in a P2P system (e.g., non-memory data bitfields) may not be considered as data in a bus system.